home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 190 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.3 KB
  1. Date: Wed, 31 Mar 93 07:19:14 -0800
  2. From: ersmith@netcom.com (Eric R. Smith)
  3. Message-Id: <9303311519.AA07587@netcom4.netcom.com>
  4. To: mint@atari.archive.umich.edu
  5. Subject: Re: Shared Libraries.
  6.  
  7. >>A shared library will be implemented as a DRI format object file, with
  8. >>the GST long name symbol table. A program linked with shared libraries
  9. >>will have the same format, but with an additional header prepended
  10. >>which gives the names and version numbers of the shared libraries it
  11. >>requires.
  12.  
  13. >Hmm... why are you thinking about using such a mixed bag of formats? Why did
  14.  
  15. ? Both shared libraries and programs linked with them would be DRI object
  16. files. The "GST long name symbol table" is a (minor and quite widely
  17. supported, including by gcc) extension to the DRI symbol table format.
  18.  
  19. Unix "ar" format wouldn't be suitable because a shared library isn't a
  20. "library" in the sense of an ar file, but rather it's a single object
  21. (more like an object file).
  22.  
  23. >What you suggest seems fine for the 68000 based machines, but for the 68030
  24. >based machines it seems a bit of a munge, why not give all processes on
  25. >these machines the same virtual address space and map the shared library
  26. >objects into that address space?
  27.  
  28. I don't want to have to implement shared libraries twice. Obviously it
  29. would be much easier to throw out 68000 support altogether, but I really
  30. don't want to do that.
  31.  
  32. >>------------------------------------------------------------------------------
  33. >>| A's data |   FOO's data |   C's data  |  D's data  |  more of FOO's data   |
  34. >>------------------------------------------------------------------------------
  35.  
  36. >What happens if FOO needs A, B, C & D? This scheme also means that all the
  37. >library modules will have to be loaded at load time instead at first call
  38. >time (doesn't it?).
  39.  
  40. If FOO needed library B, then it's data would have gone in between A's
  41. data and C's (i.e. all of FOO's own data would have been contiguous).
  42.  
  43. It is true that all the library modules for a program would have to be loaded
  44. at program load time, rather than when the library is first called. I don't
  45. think that this would generally be much of a problem; I doubt there are all
  46. that many cases where a shared library is linked but never called at run time.
  47.  
  48. >How about an alternative....
  49.  
  50. >(1) Have in the kernel a table of currently loaded modules, each with a
  51. >    reference count.
  52. >(2) Modules are loaded into an arbitary memory location with a read-only
  53. >    copy of their initialised data space at the time of first reference
  54. >    and a copy of the initialised data space is placed in the process'
  55. >    shared lib data segment, which is separate from it's own data
  56. >    segment. The total size of the shared library data segment is 64K on
  57. >    the 68000 based machines and "unlimited" on 68030 based machines,
  58. >    there is no limit imposed upon the normal data segment. Shared data
  59. >    is accessed via an offset table.
  60. >(3) Modules are deleted once the last program to use them exits, or
  61. >    alternatively... The kernel table has a timer which is added to
  62. >    every time a module is accessed. After n context switches, any
  63. >    module which has not been accessed in that time could be deleted
  64. >    from memory and a flag in the table set to say that the module is
  65. >    active but not in memory. When the module is next accessed, it is
  66. >    re-loaded, but the data space is not copied to the currently running
  67. >    program. This would improve memory usage no end, especially if
  68. >    modules were of a fixed size or a multiple of a fixed size, no
  69. >    memory fragmentation! This would give a sort of virtual memory even
  70. >    for 68000 based machines.
  71.  
  72. (1) is obviously necessary for any shared library scheme :-).
  73. (2) is reasonable, albeit slower (because of the extra indirection). The
  74. shared library data segment would actually be limited in size to 64K items,
  75. rather than 64K bytes (hmmm, actually 16K items, I guess, given 32 bit
  76. offsets).
  77. (3) is attractive, but I don't think it's workable. Or rather, it may not
  78. be as useful as it seems. The module memory can't be re-used for anything
  79. else (including program malloc requests), so there would be a win only
  80. when the program is linked with a lot of large shared libraries which are
  81. not all needed at the same time. This may be the case for X (:-)) but probably
  82. not for very many other libraries; and given the number of MiNT specific
  83. X implementations on the ST, this may not be much of a win :-(.
  84.  
  85. Thanks for your input, 
  86. Eric
  87.